1. Technical Field
The present invention relates in general to controlling a data processing system after startup, but before control is passed to the main operating system and in particular to use of an Open Firmware user interface as a debugging tool.
Still more particularly, the present invention relates to debugging an Open Firmware boot routine before the main operating system is installed.
2. Description of the Related Art
In most data processing systems (or computers), a Basic Input Output System ("BIOS") is required at startup. BIOS is essential microcode that tests computer hardware at startup, hands over operation to the main operating system and handles data transfer between hardware devices in the data processing system. The BIOS is generally stored in non-volatile, read-only memory ("ROM") so that it may be executed when the system is turned on. The combination of the stored microcode and hardware is termed "firmware." Instructions, generally low level assembly code, are written in code as software and stored into ROM memory which then becomes part of the hardware in the computer.
Developers of "boot" microcode (microcode utilized to start a data processing system) usually employ both hardware and software tools to debug newly developed code.
Generally, the code language contains, or makes available, a specific debugger to correct errors in the new code. Errors may occur when the new code is loaded onto memory and at startup there may not be enough information available to diagnose and fix the problem.
Boot "firmware" is ROM based software that is automatically run when a data processing system is switched on. A primary function of boot firmware is to perform a few basic hardware tests, then load and execute (boot) the primary operating system. A secondary function included in the boot firmware is providing tools for debugging faulty hardware or software.
"Open Firmware" is a non-proprietary standard for boot firmware that is usable on different processors and buses and the terms Open Firmware and boot firmware will be utilized interchangeably. Open firmware is firmware that complies with IEEE Standard 1275-1990 and provides an interface independent of processor types. This allows a peripheral device added to the data processing system, to identify itself and supply a boot driver that will allow the device to be utilized on any system. Boot firmware conforming to IEEE Standard 1275-1990 also includes a user interface with debugging capabilities that allows operating systems and system loaders to utilize boot firmware to assist in a system configuration and initialization process.
IEEE Standard 1275-1990 also specifies a processor independent mechanism by which a system can interrogate and configure expansion devices and install device drivers.
In a firmware environment, boot firmware encodes drivers in a machine-independent language called Fcode, a byte-coded intermediate language for the Forth programming language. Forth is based on a stack-oriented "virtual machine" that may be implemented on virtually any computer and when testing newly developed Forth code, an existing Forth code debugger is utilized to resolve errors. Using Fcode, the boot process builds a device tree, which is a hierarchical data structure describing the system hardware.
Plug-in devices describe their own characteristics with Fcode and the characteristics are stored in the device tree.
Fcode drivers are compiled into system RAM for later execution and may be utilized on data processing systems with different processor types. When a boot firmware image (a copy of ROM based boot firmware) is loaded into system memory, the boot firmware interpreter evaluates and expands boot firmware byte code into machine codes. During the execution of the expansion from Fcode into machine codes, errors can occur due to new codes being added or a new device with Fcode being probed. These errors cause the Boot firmware to take exceptions and halt the system. Generally, there is not enough information to debug these errors. Most of the time, developers need to rely on hardware debug tools to resolve errors.
FIG. 3 depicts a high-level flow chart describing the boot process, utilizing Open Firmware, as is known in the prior art. The process begins with step 300, which depicts power being turned on. The process continues to step 302, which illustrates a loader within the boot firmware loading or copying the boot routine, in this case Open Firmware, into system memory. The process next passes to step 304, which depicts the processor executing the boot routine that has been copied into system memory. The process then proceeds to step 306 which illustrates the processor executing the Forth interpreter. The process next passes to step 308, which depicts the full Open Firmware image (copy) executing.
The process passes to step 310, which illustrates Open Firmware exploring the system bus for devices. The process next proceeds to step 312, which depicts Open Firmware building a device-tree by loading device drivers of system components (buses, plug-in devices, etc.) into system memory. This device tree represents physical connections between devices and may be utilized by the operating system to configure itself, locate particular devices, attach device drivers and so on.
The process next passes to step 314, which depicts Open Firmware creating an execution environment (typically utilizing a Forth language compliant kernel) and loading the primary operating system to memory. At this point the primary operating system can utilize the Open Firmware drivers or it can load its own drivers and erase the boot image from memory. The process then continues to step 316, which illustrates the operating system taking control of the data processing system.
Low level firmware debug is a very difficult and a common problem for the computer industry as a whole, often requiring hardware assistance. Generally, boot firmware has an interpreter that provides a set of programmable debugging features to allow system problems to be isolated in the event of failure.
It would be desirable therefore, to provide a debugging tool to debug the above mentioned errors during Boot firmware execution. Additionally, it would be desirable to maintain a firmware debugger in the system which may help to resolve errors when testing newly developed Boot firmware Forth code.